Proposed by Angelina Chekanova (profile, biography) Don't forget to submit this proposal to official Google Melange site too!
How will I do that project
- I will install Glorp and Magritte and write a simple web application, using Glorp and Magritte frameworks, in order to learn them. This application will illustrate why the refactoring is important and will be used like a specific test: it must become easier when the refactoring is over.
- Investigate the frameworks, that is find information about their functionality. Learn Smalltalk language - analyse examples and object-oriented approach in the language. Learning Smalltalk will help to investigate the frameworks better.
- Choose the best implementation of common aspects and compile the code.
- Do the refactoring.
- Clean up Glorp from "common metamodeling" and "generic ORM".
- Test the resulting code with Glorp and Magritte test suites.
What methodologies will I use
I will read the documentation and analyse the examples. I will ask mentor about recommended books or presentations. If I have questions, I will ask them.
Suggested timeline and milestones
Deadline: June, 12
Milestones:
- Investigate Glorp and Magritte.
- learn about frameworks
- write simple web application, using Glorp and Magritte frameworks, in order to learn them. This application will illustrate why the refactoring is important and will be used like a specific test: it must become easier when the refactoring is over.
Deadline: July, 12
Milestones:
- Observe two projects: one is for Magritte-based SQL mapping without GLORP, another one - generator of simple GLORP mappings with Magritte descriptors.
- Choose the best implementation of these common Glorp and Magritte aspects and compile it:
- Accessors. Both GLORP and Magritte have selector accessors and direct accessors. Magritte has some extra types, like chain or pluggable accesors.
- Where-clauses of GLORP and conditions of Magritte. If they will be the same, it will be possible to check where-clause before/without database.
- Expressions of GLORP and conditions of Magritte. They are almost similar. And it make sense to "generalise" expression ideology in Magritte, as well as it's made in GLORP: you then may use similar mechanics for where-expressions, calculable fields, sorting rules and so on.
- Sorters. Both Magritte and GLORP have tools for sorting and backsorting. Interesting question: how to convert "compare blocks" to "compare fields expressions", and is this possible at all.
- Field types. Almost similar, but very different mechanics are used now. For example, different classes are used for different database platforms, and maybe it's not good, especially if talking to SqueakDBX integration.
- Detect any limitations of one framework revealed by comparison with the other.
- Refactor and split the stuff to three groups: "common metamodeling", "Generic ORM" and "GLORP-related".
Deadline: August, 9
Milestones:
- Choose the best implementation of these common Glorp and Magritte aspects and compile it:
- Tracking changes. Internal structure is quite similar. We have object with initial values saved, compare can be used to determine updates, and saved object can be used for rollback as well.
- Descriptors. GLORP's classModels and descriptorFor's are quite similar to Magritte descriptors.
- General database information. Like "table to store objects of those kind", "key fields", "this object's field are linked to those database table link". Not really a similarity between GLORP and Magritte, but quite common aspect of database realting, not only GLORP-based.
- Continue refactoring and detecting limitations.
- Clean up Glorp from "common metamodeling" and "Generic ORM" stuff. Cleaning up Glorp will not take a lot of time, because the code will be compiled when I do the refactoring (when choosing common aspects).
- Observe some other projects if I have enough time.
Deadline: August, 16
Milestones:
- Test the code on Glorp and Magritte test suites and use the written web application for tests.
Where I see the risks
May be there are many limitations for Glorp/Magritte and so the refactoring is not effective.
Also the task can take a lot of time, perhaps there is a lot of code to analyse.
How the results will look like
The result will look like the refactored codeset, three levels of abstraction and analysis why the code was refactored in that way.
|